Facilitating cross-platform content access

ABSTRACT

A messaging system includes features of gathering information regarding content accessed across multiple applications and/or devices and making that information available to account holders of the messaging system. The messaging system stores data related to accessed content in a plurality of indices and makes that data available to enable account holders to access previously-accessed content, even if the previous access occurred in a different software application, on a different device, or on a device with a different operating system. Account holders may also be provided with recommendations based on gathered information.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.15/826,358 filed Nov. 29, 2017, now allowed, which is a continuation ofSer. No. 14/699,926, filed Apr. 29, 2015, now U.S. Pat. No. 9,866,586,issued Jan. 9, 2018, which application claims the benefit of U.S.Provisional Application No. 61/986,815, filed Apr. 30, 2014, which isincorporated by reference in its entirety.

BACKGROUND

The disclosure generally relates to mobile device software, andparticularly to facilitating access to content on a mobile device.

There is a wide range of software applications that allow mobile deviceusers to access content. These applications typically provide a userwith some combination of text, images, and software constructs. Oftenthese applications include a history log of what content a user hasaccessed within the application.

However, a mobile device user may access content within dozens ofdifferent software applications. Further, the user may use multipledevices to access content. If the user does not remember the applicationor device on which a particular content item was accessed, it may bedifficult to find the content item even if it is stored in a history logof one of the dozens of applications. Manually searching through eachsoftware application on a particular device or a set of devices takestime and effort. Further, users use different devices at differenttimes, and may desire to access a content item on a different devicerunning a different operating system from the device originally used toaccess the content. Finding a previously accessed content item is not atrivial task, and may discourage users from using applications to accesscontent because the time and effort required to access a previouslyaccessed content item may make other options for accessing content moreattractive.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates the computing environment for facilitating contentitem access within client computing devices, according to oneembodiment.

FIG. 2 illustrates the logical components of a messaging server,according to one embodiment.

FIG. 3 is a flowchart of the steps for an example process for storinginformation associated with access occurrences, and providing thatinformation to enable account holders to access content items.

FIG. 4 illustrates example account index entries, which associate thecontent items accessed by each account holder, according to oneembodiment.

FIG. 5 illustrates example correlation index entries, which associatecontent items with content item addresses corresponding to variousoperating systems, according to one embodiment.

FIG. 6 illustrates example aggregated index entries corresponding toaggregated content item views and application use, according to oneembodiment.

FIG. 7 illustrates example aggregated account index entriescorresponding to account-holder-specific content item views andapplication use, according to one embodiment.

The Figures (FIGS.) and the following description relate to exampleembodiments by way of illustration only. It should be noted that fromthe following discussion, alternative embodiments of the structures andmethods disclosed herein will be readily recognized as viablealternatives that may be employed without departing from the principlesof what is claimed.

DETAILED DESCRIPTION I. Configuration & Operation Overview

A messaging system includes features of gathering information regardingcontent accessed across multiple applications and devices and makingthat information available to account holders of the messaging system.In one embodiment, software code representing a common applicationcomponent is added to a software application, for example, by adeveloper of the software application including software code providedas part of a software development kit (SDK) available for use in theapplication code. The common application component sends a data entry tothe messaging system when a content item is accessed. The data entrysent by the common application component may relate to the content itemitself, the application used to access the content item, or the devicerunning the application. An index module of a messaging server receivesthe data entry and stores various elements in one or more indices in anindex repository.

Indices in the index repository may include an account index, whichcontains entries that associate the content items accessed by eachaccount holder of the messaging system. An example account index entrycomprises an account identifier, an application identifier, and acontent item identifier. The account index data associated with anaccount holder may be provided to the account holder in the form of alist of content items.

Indices in the index repository may further include a correlation index,which contains entries that associate content items with content itemaddresses corresponding to various operating systems. An examplecorrelation index entry comprises a content item identifier, anapplication identifier, an operating system identifier, and a contentitem address. A correlation index entry may further include the actualmedia contents of of a content item (e.g., text) to enable text or othercontent-based searching. A content identifier and an applicationidentifier correspond to a particular content item and applicationrespectively, but do not vary across different operating systems. Acontent item address corresponds to an instance of a content item withinan application running on a particular operating system. Correlationindex data for a particular content item may be received responsive tocontent item access by multiple account holders.

The content item access events stored in the account index, andcorrelation entries stored in the correlation index facilitate ease ofaccess across computing platforms having different operating systems.For example, if an account holder accesses a content item using anapplication on an APPLE IPAD™ running the IOS™ operating system, theseindices together allow the account holder to conveniently and directlyaccess the content item using the same application on their smartphonerunning the ANDROID™ operating system, even if the account holder hadnever before accessed the content using their smartphone. In thisexample, the account index provides a content item access log of allcontent items accessed by the account holder regardless of device oroperating system used, and the correlation index allows for immediateretrieval and navigation to that content within the associatedapplication on any of the account holder's devices without requiring theaccount holder to navigate in a traditional manner through theapplication to that particular content item. This ease-of-use from theaccount holder's perspective is provided by the cross platform/operatingsystem compatibility provided by the account and correlation indices.These indices are populated by content item access events reported byapplications including code from the SDK mentioned above. As the SDKcode can be incorporated into any application regardless of operatingsystem, this solution is easily extendable to existing applications aswell as any future applications. This is particularly useful for mobilesoftware applications, that have more restrictive operating systems forthis kind of reporting than, for example, traditional desktop computers,and may also be useful for other types of computing platforms andoperating systems.

Recommendations for additional content items or applications related tocontent items may be provided in association with the list of contentitems. The index module may receive a request to access a content item(e.g. responsive to the account holder interacting with the list). Theindex module retrieves and sends a content item address corresponding tothe content item and the operating system of the requesting device.Using the content item address, an account holder may directly accessthe content item within the corresponding application and operatingsystem combination.

II. Computing Environment

FIG. 1 illustrates the computing environment for facilitating contentitem access within client computing devices, according to oneembodiment. The environment includes a client device 110, a network 120,a front end server 140, a number of messaging server instances 130, anda database 160.

Account holders use client devices 110 to access the messaging system100 to publish messages, view and curate their streams, and view andinteract with lists of content items. A client device 110 is a computerincluding a processor, a memory, and generally any one or more of adisplay, an input device, and a wired and/or wireless network device forcommunicating with the front end server 140 of the messaging system 100over network 120. For example, a client device 110 may be a desktopcomputer, a laptop computer, a tablet computer, a smart phone, or anyother device including computing functionality and data communicationcapabilities.

The processor of the client device 110 operates computer software 112configured to access the front end server 140 of the messaging system100 so that the account holder can publish messages, view and curatetheir streams, and view and interact with lists of content items. Thesoftware 112 may be a web browser, such as GOOGLE CHROME™, MOZILLAFIREFOX™, or MICROSOFT INTERNET EXPLORER™. The software 112 may also bea dedicated piece of software designed to work specifically with themessaging system 100. Generally, software 112 may also be a ShortMessaging Service (SMS) interface, an instant messaging interface, anemail-based interface, an API function-based interface, etc. In variousembodiments, the processor of client device 110 operates an operatingsystem.

The processor of client device 110 may operate software application 114.A client device 110 may operate multiple applications 114. In someembodiments, client device 110 may be configured to operate multipleapplications 114 simultaneously. Examples of applications 114 includeweb browsers (e.g. GOOGLE CHROME™, MOZILLA FIREFOX™, MICROSOFT INTERNETEXPLORER™, etc.), messaging services (FACEBOOK™, TWITTER™, etc.), andother mobile applications (GOOGLE MAPS™, FLIPBOARD™, NYTIMES™, AMAZON™,etc.). Applications 114 may execute in conjunction with an operatingsystem of a client device 110. Example operating systems include APPLEIOS™, GOOGLE ANDROID™ MICROSOFT WINDOWS PHONE™, MICROSOFT WINDOWS 8™,APPLE OSX™, etc.

Each application 114 has an associated application identifier (ID). Theapplication ID is independent of the operating system within which theapplication 114 is executing, which means that different instances of anapplication executing on different client devices 110 having differentoperating systems still have the same application ID. The application IDmay be required to be a domain (e.g. a verified web address) to deterimpersonation by unknown parties.

The network 120 may comprise any combination of local area and/or widearea networks, the internet, or one or more intranets, using both wiredand wireless communication systems.

The messaging system 100 generally provides account holders with theability to publish their own messages and view messages authored byother accounts. Messages may take of variety of forms including, digitaltext, videos, photos, web links, status updates, blog entries, tweets,profiles, and the like. The messaging system 100 may also providevarious complementary services such as those provided by socialnetworks, blogs, news media, forums, user groups, etc. An example of amessaging system 100 is TWITTER™. The messaging system 100 is adistributed network including multiple computing devices, where eachcomputing device in the system includes computer hardware specificallychosen to assist in the carrying out of its specific purpose.

Client 110 interfaces with the messaging system 100 through a number ofdifferent but functionally equivalent front end servers 140. The frontend server 140 is a computer server dedicated to managing networkconnections with remote clients 110. As the messaging system 100 mayhave many millions of accounts, there may be anywhere from hundreds ofthousands to millions of connections being established or currently inuse between clients 110 and the front end server 140 at any given momentin time. Including multiple front end servers 140 helps balance thisload across multiple countries and continents.

The frontend module 140 may provide a variety of interfaces forinteracting with a number of different types of clients 110. Forexample, when an account holder uses a web browser 112 to access themessaging system 100, a web interface module 132 in the front end module140 can be used to provide the client 110 access. Similarly, when anaccount holder uses an item of software 112 that calls an API 134 madeavailable by the messaging system 100 for such a purpose, an APIinterface module 134 can be used to provide the client 110 access.

The front end server 140 is further configured to communicate with theother backend computing devices of the messaging system 100. Thesebackend computing devices carry out the bulk of the computationalprocessing performed by the messaging system 100 as a whole. The backendcomputing devices carry out any functions requested by a client 110 andreturn the appropriate response/s to the front end servers 140 forresponse to the client 110.

The backend computing devices of the messaging system 100 include anumber of different but functionally equivalent messaging servers 130which are each associated with at least one messaging database 160. Thecomponents and behavior of the messaging servers 130 including theillustrated index modules 136, and databases 160 and the illustratedindex repositories 162, are described immediately below with respect toFIG. 2.

III. Messaging Server

FIG. 2 illustrates the logical components of a messaging server 130,according to one embodiment. Each messaging server 130 handles at leastthe basic messaging functionality of the messaging system 100. Thisbasic functionality includes at least publishing new messages, providingmessage streams to be provided upon client request, managing accounts,managing connections between accounts, messages, and streams, andreceiving engagement data from clients engaging with messages. Eachmessaging server also handles indexing of content item access data andproviding of indexed data to account holders, as discussed below withrespect to FIGS. 3-7.

Each messaging server 130 includes a routing module 210, a graph fanoutmodule 220, a delivery module 230, an account module 240, an engagementmodule 250, and an index module 136. Each messaging server 130 iscommunicatively coupled with an associated database 160 which storesdata locally for convenient access by the associated messaging server130. Each database 160 includes a message repository 212, a connectiongraph repository 222, a stream repository 232, an account repository242, an engagement repository 252, and an index repository 162.

In the messaging system 100, messages are containers for a variety oftypes of computer data representing content provided by the composer ofthe message. Types of data that may be stored in a message include text(e.g., 140 character Tweet), graphics, video, computer code (e.g.,uniform resource locators (URLs)), or other content. Messages can alsoinclude key phrases (e.g., symbols, such as hashtag “#”) that can aid incategorizing or contextualizing messages. Messages may also includeadditional metadata that may or may not be editable by the composingaccount holder, depending upon the implementation. Examples of messagemetadata include the time and date of authorship as well as thegeographical location where the message was composed (e.g., the currentphysical location of the client 110). Message are not only arepresentation of the written text, video, or audio media, but also arepresentation of that content captured within an electronicrepresentation, and stored as data within a computing device.

The messages composed by one account holder may also reference otheraccounts. For example, a message may be composed in reply to anothermessage composed by another account. Messages may also be repeats (orreposts) of a message composed by another account. Generally, an accountreferenced in a message may both appear as visible content in themessage (e.g., the name of the account), and may also appear as metadatain the message. As a result, the messaging system 100 is able to allowthe referenced accounts to be interactive. For example, clients 110 mayinteract with account names that appear in their message stream tonavigate to the message streams of those accounts. The messaging system100 also allows messages to be private, such that a composed messagewill only appear in the message streams of the composing and recipientaccounts.

The routing module 210 stores newly composed messages received throughthe frontend module 110 in the message repository 212. In addition tostoring the content of a message, the routing module 210 also stores anidentifier for each message. The identifier provides a piece ofinformation that can be used to identify that the message is to beincluded in a message stream. This allows the message to be stored onlyonce, and accessed for a variety of different message streams withoutneeding to store more than one copy of the message.

The graph module 220 manages connections between accounts, therebydetermining which streams include messages from which accounts. In oneembodiment, the messaging system 100 uses unidirectional connectionsbetween accounts (or streams) to allow account holders to subscribe tothe message streams of other accounts. By using unidirectionalconnections, the messaging system 100 allows an account holder toreceive messages that appear in one of the streams of one of the otheraccount holders, without necessarily implying any sort of reciprocalrelationship the other way. For example, the messaging system 100 allowsaccount holder A to subscribe to the message stream of account holder B,and consequently account holder A is provided and can view the messagesauthored by account holder B. However, this unidirectional connection ofA subscribing to B does not imply that account holder B can view themessages authored by account holder A. This could be the case if accountholder B subscribed to the message stream of account holder A; however,this would require the establishment of another unidirectionalconnection. In one embodiment, an account holder who establishes aunidirectional connection to receive another account's message stream isreferred to as a “follower”, and the act of creating the unidirectionalconnection is referred to as “following” another account. The graphmodule 220 receives requests to create and delete unidirectionalconnections between accounts through the frontend module 140. Theseconnections are stored for later use in the connection graph repository222 as part of a unidirectional connection graph. Each connection in theconnection graph repository 222 references an account in the accountrepository 242 or a stream in the stream repository 232.

In the same or a different embodiment, the graph module 220 managesconnections between accounts using bidirectional connections. Uponestablishing a bidirectional connection, both accounts are consideredsubscribed to each other's account message stream(s). The graph modulestores bidirectional connections in the connection graph repository 222.In one embodiment, the messaging system 100 and connection graphrepository 222 include both unidirectional and bidirectionalconnections. Additionally, the connections (both unidirectional andbidirectional) are electronic representations of relationships betweenphysical entities.

The delivery module 230 constructs message streams and provides them torequesting clients 110 through the frontend module 140. Responsive to arequest for a stream, the delivery module 230 either constructs thestream in real time, or accesses some or all of a stream that hasalready been generated from the stream repository 232. The deliverymodule 230 stores generated streams in the stream repository 232. Anaccount holder may request any of their own streams, or the streams ofany other account that they are permitted to access based on securitysettings.

The messages included in a stream may have been authored by a connectedaccount while both accounts are simultaneously accessing the messagingsystem 100. The messages included in a stream also include messagesauthored in the past by accounts that are not currently accessing themessaging system 100. As introduced above, the contents of a messagestream for a requesting account holder may include messages composed bythat account holder, messages composed by the other accounts that therequested account holder follows, and messages authored by otheraccounts that reference the requested account holder. The messages of astream may be ordered chronologically by time and date of authorship, orreverse chronologically. Other orderings may also be used, such asaccording to their inferred relevance to the account holder, or somecombination of time and relevance rankings.

A stream has the potential to include a large number of messages. Forboth processing efficiency and the requesting account holder's viewingconvenience, the delivery module 230 generally identifies a subset ofpossible messages for sending to the client 110 once the stream isgenerated. The remainder of the messages in the stream are maintained inthe stream repository 232, and sent upon client 110 request.

The account module 240 provides functionality allowing an account holderto manage their account with the messaging system 100, and is one meansfor doing so. The account module 240 allows the account holder to manageprivacy and security settings, as well as directly manage theirconnections to other account holders. Generally, the messaging system100 does not require the account holder to contribute a large amount ofpersonal information. This personal information can include an accountname (not necessarily a real name) or identifier (ID), provides picturesof media, provide a brief description of themselves/their entity, and awebsite. The personal information does not necessarily include (and maypurposefully exclude) traditional real-world identifying informationsuch as age, gender, interests, history, occupation, etc. In oneembodiment, account module 240 assigns an account identifier (ID) toeach account. Provided information is stored in the account repository242.

The message client software 112 allows account holders receiving astream to engage (e.g., interact) with the messages in the stream.Engagement module 250 receives these engagements and stores them in theengagement repository 252. There are a number of different types andcategories of engagements. Types of engagement includeclicking/selecting a message for more information regarding the message,clicking/selecting a URL (universal resource locator) or hashtag in amessage, reposting the message, or favoriting a message. Other exampleengagements types include expanding a “card” (or compressed) message,which presents additional (uncompressed) content when an account holderengages with the card message. Account holders may engage further withcontent contained in the expanded card message (e.g., by playing a videoor audio file or by voting in a poll). Some engagements are based onpassive behavior by the account holder with respect to a stream ormessage appearing on the client device 110.

In addition to monitoring active interactions (e.g., engagements) withmessages through explicitly received input at the client device 110 fromthe account holder, the engagement module 250 may also record passiveinteractions (e.g., impressions) with messages by accounts. Animpression occurs when an account holder views or otherwise experiencesthe content of a message through a client 110. Impression engagementsinclude the mere fact that an impression occurred, as well as otherinformation such as whether a message in a stream appeared on a displayof the client device 110, and how long the account holder dwelled on amessage appearing on the display.

Any engagement stored in the engagement repository 252 may reference themessages, accounts, and/or stream involved in the engagement, forexample via pointers to the message 212, account 242 and/or stream 232repositories.

Engagements may also be categorized beyond their type. Examplecategories include engagements expressing a positive sentiment about amessage (positive engagements), engagements expressing a negativesentiment about a message (negative engagements), engagements that allowan advertiser account to receive monetary compensation (monetizableengagements), engagements that are expected to result in additionalfuture engagements (performance engagements), or connection engagementsthat are likely to result in one account holder following anotheraccount, etc. For example, the negative engagements category includesengagements such as dismissing a message or reporting a message asoffensive while the positive engagements category typically includesengagements not in the negative engagements category. Exampleperformance engagements include selecting a URL in a message orexpanding a card. Example monetizable engagements include an engagementthat results in an eventual purchase or a software application installto the client 110. Generally, categories and types are not coextensive,and a given type of engagement may fall into more than one category, andvice versa.

IV. Common Application Component

As shown in FIG. 1, in various embodiments, application 114 enables anaccount holder of the messaging system 100 to access content (e.g.,text, images, software constructs, etc.). More specifically, a contentitem is an instance of one or more pieces of content associated with anapplication 114. A content item may, for example, be a softwareconstruct generated according to application computer programinstructions (code). Content items may also be downloaded to a clientdevice 110 via network 120 (e.g. a news story comprising text and imagesdownloaded from the internet).

Applications 114 may include a common application component 116 thatsends information to the messaging system 100 when a content item isaccessed. Information sent by the common application component 116 mayrelate to the content item itself, the application 114 used to accessthe content item, the operating system of the device, and/or the devicerunning the application. Common application component 116 may send datadirectly to index module 136, or indirectly via a front end server 140.In one embodiment, software code for the common application component116 is distributed to developers of applications as a softwaredevelopment kit (SDK). A developer may add the software code to thesource code of an application 114 that causes the application to senddata to index module 136 upon the happening of an event (e.g., accessinga content item within the application). Multiple different instances ofthe code may be added to the source code of an application 114 thatcauses the application to send data upon the occurrence of multipledifferent events within the application. Which events cause theapplication 114 to send data are at the discretion of the developer ofthe application 114.

The common application component 116 is capable of being integratedwithin multiple different applications 114 across several client devices110, including those with different operating systems. Accordingly,common application component 116, in conjunction with index module 136and index repository 162 may be used to collect and store informationregarding content items accessed by multiple, different applications anddevices. The stored information may be used to save for later access thecontent items accessed by a single account holder across multipledifferent applications and devices. It may further be provided to theaccount holder or to other account holders of the messaging system 100to facilitate content item access and other functions of client devices110.

V. Content Item Access and Index Entry Creation

Access of a content item may occur when the content item is requestedand/or provided from the messaging system 100 to a client device 110.Additionally, access of a content item may also occur when an accountholder interacts (or engages) with the content item, regardless ofwhether the content item is actually displayed on a display of theclient device. Accesses may also be recorded as engagements, asintroduced above. Examples of actions that can trigger a content itemaccess include, but are not limited to, clicking a hyperlink on a webpage displayed within a client device 110, receiving a touch interactionwithin a software application 114 running on the client device 110.

FIG. 3 is a flowchart of the steps for an example process for storinginformation associated with access occurrences, and providing thatinformation to enable account holders to more easily access contentitems. When a content item is accessed by an instance of an application114, common application component 116 of a first client device 110 sendsa data entry about the access occurrence to messaging system 100. Thedata entry is received 310 by the front end server 140 and subsequentlyrelayed to index module 136. In one embodiment, the data entry comprisesan application event, an application identifier (ID), a content itemidentifier (ID), and a content item address. In another embodiment, thedata entry may further comprise the accessed content item. Data entryelements are stored in one or more indices (e.g., an account index 400,a correlation index 500, an aggregated index 600, and an aggregatedaccount index 700) in index repository 162, as discussed with respect toFIGS. 4 and 5 below.

An application event identifies that the content item was accessed. Anapplication event may include information associated with the accessoccurrence, such as when the content item was accessed, what clientdevice 110 and operating system were used to access the content item, ageographic location where the client device 110 was located when thecontent item was accessed.

An application ID, as discussed above, identifies an application 114 andis independent of the operating system within which the application isexecuting, which means that instances of an application executing ondifferent client devices using different operating systems have the sameapplication ID.

A content item ID uniquely identifies a content item, at least within anapplication if not globally across many if not all applicationsassociated with the common application component. Each content itemaccessed by application 114 may be associated with a content item ID, ifthe developer of the application 114 so chooses. For a particularcontent item, a content item ID is the same at least across differentinstances of the same application 114 operating on different clientdevices including those running different operating systems. The contentitem ID may also be the same across multiple applications 114 associatedwith the common application component.

A content item ID may be assigned to a content item in a variety ofways. For example, a content item ID may be included with a content itemwhen it is sent from a server of an application 114 to the variousinstances of application 114. A content item ID may also be assigned bythe messaging system 100.

A content item address (also commonly referred to as a “deep link”),specifies where the content item can be directly accessed within anyinstance of an application 114 operating on a client device 110 thatuses a particular operating system. The content item address is specificto an instance of a content item within a particular application 114running on a particular operating system. As a result, the content itemaddress can directly access the content item within the correspondingapplication 114 and operating system combination, but cannot directlyaccess the content item within another application 114 on a sameoperating system or within a same software application on anotheroperating system. Each content item may be associated with one or morecontent item addresses. For some types of applications 114 such as webbrowsers, a content item address is a Uniform Resource Locator (URL).For other types of applications 114 such as applications that operate onmobile computing devices (e.g., smart phones running the ANROID™ or IOS™operating systems), the content item address is a logical address thatis not URL.

Upon receipt of the data entry from the client device regarding thecontent item access, the index module 136 adds 315 a new account indexentry to an account index 400. The account index 400 keeps a log ofcontent item accesses by an account holder of the messaging system 100for their later use. The new account index entry includes theapplication ID and content item ID from the data entry. The account IDassociated with the data entry may be received by index module 136 aspart of the data entry, or it may be retrieved from messaging database160, for example, if the account holder has logged into their accountwith the messaging system 100 from the client device 110 from which thedata entry was received. In one embodiment, the new account index entryalso includes an operating system identifier (OS ID) corresponding tothe operating system associated with the access occurrence.

FIG. 4 illustrates example account index entries, which lists thecontent items accessed by each account holder, according to oneembodiment. For example, as shown in FIG. 4, keys 410 of the accountindex may include account ID entries 412 (e.g., ‘@camera&carl’), withcorresponding values 420 including the application ID entries 422 (e.g.,‘app.news.com’) and content item ID entries 424 (e.g., ‘78704’)associated with a particular content item. As a result, index module 136can provide the content items accessed by a particular account holderback to the account holder upon request.

Returning again to FIG. 3, index module 136 also adds 320 a newcorrelation index entry to a correlation index 500. The correlationindex 500 correlates content item addresses by content item ID acrossmultiple account holders, to provide a central repository of the varietyof content item addresses (e.g., deep links) available to be used toaccess that content item ID. Thus, if an account holder has accessed afirst content item ID on a first device/operating system combination butnot a second device/operating system combination, as long as some otheraccount holder of the messaging system has accessed that content item IDwith the second device/operating system combination, the correlationindex will have stored the content item address for that combination,thus allowing the account holder to use a device having the seconddevice/operating system combination to access that content item IDquickly, for example through use of a log of content item ID accessessuch as may be provided by the access index 400.

The correlation index 500 includes the content item ID, the OS ID, andthe content item address from the received data entry. The correlationindex may also include the application ID. Entries in the correlationindex associated with a particular content item may be received atdifferent times from different client devices 110, and from clientdevices associated with different account holders. FIG. 5 illustratesexample correlation index entries, which associate content items withcontent item addresses corresponding to various operating systems,according to one embodiment. For example, as shown in FIG. 5, keys 510of the correlation index may include content item ID entries 512 (e.g.,‘78704’), application ID entries 514 (e.g., ‘app.news.com’), and OS IDentries 516 (e.g., ‘iOS’). Values 520 may include content item addressentries 522 (e.g., ‘Appl.news.com/78704’). Particular content item IDentries and application ID entries may appear in both account index 400and correlation index 500. Each combination of a content item ID and anapplication ID (e.g., ‘78704.app.news.com’) corresponds to an instanceof a content item within a particular application, but does not varyacross operating systems or client devices. Thus, to retrieve a contentitem address corresponding to an application executing in conjunctionwith a particular operating system, the index module 136 uses the OS ID.From the correlation index 500, index module 136 can determine variouscontent item addresses associated with different operating systems for asingle content item ID.

The actual media content of a received content item may be indexed andstored in correlation index 500 to enable text or other content-basedsearching. For example, if a content item includes text, the text may bestored in correlation index 500. The text may be stored such that indexmodule 136 may receive a text query from a device of an account holderand return to the device a list of content items that match the query.The list may be sorted based on a relevance score, which is discussed inmore detail below. An account holder may view and interact with the listof matching content items to access the content items, as discussed inmore detail below.

VI. Index Use

An account holder may use software 112 or an application 114 to view alist of content items (e.g., previously-accessed content items, contentitems matching a search query, etc.). In the example process of FIG. 3,upon receipt of a request from a client device 110 associated with theaccount holder, the index module 136 sends 325 a list of account indexentries corresponding to the account ID of the account holder to aclient device 110. To illustrate the use of the correlation index 500,the client device 110 that the index module 136 sends the account indexentries to is referred to as the second client device 110, running asecond operating system. This is distinguished from a first clientdevice 110, running a first operating system different than the secondoperating system.

The list of content items sent by the index module 136 to the secondclient device 110 may be interactive, allowing an account holder toaccess the content items listed in the entries by interacting with thelist (e.g. tapping, clicking, etc.) on their client device. Interactingwith a list item may cause the client device 110 to navigate to acontent item address, which may include executing applications 114 onthe device and navigating to particular content item addresses withinthose applications so that the content item is presented by the clientdevice within the associated application 114.

The index module 136 receives 330 a request to access a content itemfrom the second client device 110. For example, the request may specifythe content item ID of the content item to be accessed. The content itemspecified by the request may have been previously accessed by theaccount holder on the second client device 110, or it may have beenpreviously accessed by the account holder on another client device suchas the first client device. In either of these instances, the requestmay be a result of the account holder interacting with the previouslyprovided account index entries. Alternatively, the content item accessrequest may be retrieved from another source, such as from arecommendation provided by the messaging system 100, as describedfurther below. The request received from the second computing deviceincludes the content item ID, and may also include an application ID andan OS ID of the second operating system.

The index module 136 uses the data from the request to retrieve 335,from the correlation index 500, a content item address for the requestedcontent item ID and the operating system ID. Index module 136 sends 340the retrieved content item address to the second client device 110,which allows the second client device to access the content item. Theindex module 136 may also send 340 an application ID to specify theapplication 114 to be used to access the content item.

Because the correlation index 500 is not account-specific, the retrievedcontent item address may have been added to the correlation indexresponsive to the content item being accessed by an account holderdifferent from the account holder making use of the first and secondcomputing devices. Accordingly, an account holder has access to contentitem addresses beyond just those they have already visited, for exampleas logged by the account index 400. This allows an account holder toeasily access a content item across multiple applications anddevices/operating systems, regardless of how the account holderpreviously accessed the content item (e.g., on the first computingdevice but not the second computing device) or even if the accountholder has not previously accessed the content item at all.

VII. Content Recommendations

Index module 136 may provide one or more recommendations of contentitems an account holder may be interested in accessing. Recommendationmay be provided, for example, in response to a request for a list ofaccessed content items, in response to a text query, upon interactionwith a list item, or by request from another part of the messagingsystem. Example recommendations include recommendations for relatedcontent items that have not been accessed, recommendations forapplications 114 associated with accessed content items, recommendationsfor popular content items, recommendations for popular applications,etc. For example, if a content item accessed by a client device 110 isassociated with an application 114 that has not been installed on theclient device, index module 136 may include a link (e.g. URL or otherlogical address) to a location where the application can be downloadedto the client device.

Recommendations may be based on a relevance score determined by indexmodule 136 for a particular content item or application. Factors in arelevance score may include a number of times a content item has beenaccessed (e.g., by a particular account holder, by a subset of allaccount holders, by all account holders, etc.). Factors may additionallyinclude how recently a content item was accessed, how recently a contentitem was generated, and how much time has elapsed between accesses.Factors in a relevance score may further include measures of applicationuse (e.g., by a particular account holder, by a subset of all accountholders, by all account holders, etc.), sponsor agreements withapplication or content item owners, etc. Data associated with relevancescore factors is stored in index repository 162. As an example, arecommendation for a particular application 114 may be providedresponsive to an account holder accessing a particular content item on adifferent application from the one that is most commonly used to accessthat content item. For example, a recommendation may be provided to theaccessing client device if a determined relevance score is above athreshold designated by a developer and if the corresponding application114 that is most commonly used to access the requested content item hasnot been installed on the requesting client device 110.

FIG. 6 illustrates example index entries of an aggregated index 600 thataggregates content item views across multiple account holders for use inproviding recommendations, according to one embodiment. Keys 610 includeapplication ID entries 612 and content item ID entries 614. Values 620include global view entries 622. Global view totals may be determined byindex module 136, for example by counting data entries received by indexmodule 136 or by counting index entries in the account index orcorrelation index. Index module 136 may determine application useinformation based on the views associated with a particular applicationID across multiple content item IDs. The aggregated statistics regardingcontent item IDs collected in the aggregated index 600 are used by themessaging servers 130 to determine which content item IDs to recommend.

FIG. 7 illustrates example index entries of an aggregated account index700 that aggregates content item views and application use on anaccount-holder-specific basis, according to one embodiment. Keys 710include account ID entries 712, application ID entries 714, and contentitem ID entries 716. Values 720 include account holder view entries 722.Account holder view totals may be determined by index module 136 or bycounting index entries in the account index. Index module 136 maydetermine application use information based on the views associated witha particular application ID across multiple content item IDs. Theaggregated statistics regarding content item IDs collected in theindices 600 and 700 are used by the messaging servers 130 to determinewhich content item IDs to recommend to the particular account holderassociated with each index 700.

VIII. Additional Considerations

It is noted that wherever practicable similar or like reference numbersare used in the figures and may indicate similar or like functionality.The figures depict embodiments of the disclosed system (or method) forpurposes of illustration only. One skilled in the art will readilyrecognize from the description herein that alternative embodiments ofthe structures and methods illustrated herein may be employed withoutdeparting from the principles described herein.

Some portions of this description describe the embodiments in terms ofalgorithms and symbolic representations of operations on information.These algorithmic descriptions and representations are commonly used bythose skilled in the data processing arts to convey the substance oftheir work effectively to others skilled in the art. These operations,while described functionally, computationally, or logically, areunderstood to be implemented by computer programs or equivalentelectrical circuits, microcode, or the like.

It will be understood that the named components represent oneembodiment, and other embodiments may include other components. Inaddition, other embodiments may lack the components described hereinand/or distribute the described functionality among the components in adifferent manner. Additionally, the functionalities attributed to morethan one component can be incorporated into a single component.

As noted above, the computing devices described in FIGS. 1 and 2 includea number of “modules,” which refers to computational logic for providingthe specified functionality. A module is implemented in software thatoperates on at least one computing device. Each module can beimplemented as a standalone software program, but can also beimplemented through other means, for example as part of a largerprogram, as a plurality of separate programs, or as one or morestatically or dynamically linked libraries. In any of these softwareimplementations, the modules are stored on the computer readablepersistent storage devices of the computing device(s) within which theyare located, loaded into memory, and executed by one or more processors(generally, “a processor”) of the computing device. The various dataprocessing operations described herein are sufficiently complex and timeconsuming as to require the operation of a computing device, and cannotbe performed merely by mental steps.

Embodiments described may also relate to an apparatus for performing theoperations herein. This apparatus is specially constructed for thepurpose described herein, owing to the large number of accounts,messages, streams, and related content (e.g., engagements) that areprocessed by the messaging system 100 generally, and which are processedby the messaging server 130 specifically. The tasks carried out by themessaging server 130 may be persistently stored in a non-transitory,tangible computer readable storage medium, or any type of media suitablefor storing electronic instructions, which may be coupled to a computersystem bus within the messaging server 130. Furthermore, any of thecomputing devices referred to in the specification may include a singleprocessor or may be architectures employing multiple processor designsfor increased computing capability. Embodiments of the invention mayalso relate to a product that is produced by a process described herein.Such a product may comprise information resulting from a computingprocess, where the information is stored on a non-transitory, tangiblecomputer readable storage medium and may include any embodiment of acomputer program product or other data combination described herein.

Finally, the language used in the specification has been principallyselected for readability and instructional purposes, and it may not havebeen selected to delineate or circumscribe the inventive subject matter.It is therefore intended that the scope of the invention be limited notby this detailed description, but rather by any claims that issue on anapplication based hereon. Accordingly, the disclosure of the embodimentsdescribed is intended to be illustrative, but not limiting, of the scopeof what is protectable, which is set forth in the following claims.

What is claimed is:
 1. A method for accessing content items, the methodcomprising: receiving, from a common application component making uppart of an instance of a software application executing on a firstcomputing device, a plurality of data entries comprising: a content itemincluding searchable media, a content item address specifying where thecontent item can be directly accessed within any instance of thesoftware application operating on another mobile computing device;generating, at a server, a content item ID for each data entry; adding,to a correlation index, a new correlation index entry comprising thecontent item ID, the content item, and the content item address for eachreceived data entry; determining a relevance score for each data entry,the relevance score a measure of the contents items interest to anaccount holder; receiving, from the account holder operating a secondcomputing device, a search query for a content item; generating a listof content items and their associated content item addresses, whereineach content item in the list is based on the content items relevancescore and associated with the search query; sending the list of contentitems and their associated content item addresses to the secondcomputing device.